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Abstract 

The reference RDBMS for BESSY II has been set up with 
a device oriented data model. This has proven adequate for 
e.g. template based RTDB generation, modelling etc. But 
since assigned I/O channels have been stored outside the 
database (a) numerous specific conditions had to be main- 
tained within the scripts generating configuration files and 
(b) several generic applications could not be set up auto- 
matically by scripts. In a larger re-design effort the I/O 
channels are introduced into the RDBMS. That modifica- 
tion allows to generate a larger set of RTDBs, map specific 
conditions into database relations and maintain application 
configurations by relatively simple extraction scripts. 

1 INTRODUCTION 

Within the last few years Relational DataBase Manage- 
ment Systems (RDBMS or DB in short) have become es- 
sential for control system configuration. With availability 
of generic applications and hardware standards the inter- 
play of components as well as the adaptation to site specific 
needs has become crucial. Proper networking has been the 
central problem of the past. Today's challenge is a cen- 
tral repository of reference and configuration data as well 
as an appropriate standard suite of DB applications. Target 
is a management system providing consistency in a pro- 
grammable, comprehensible and automatic way for devel- 
opment, test and production phases of the control system. 
Instead of careful bookkeeping of innumerable hand-edited 
files the ever needed modifications of the facility require 
'only' change of atomic and unique configuration data in 
the DB and eventually adaptation of structures in the DB 
(applications). The update of tool configurations is then 
consistently accomplished by direct DB connection, re- 
newal of snapshot files generated by extraction scripts etc. 

2 STATUS AND ACHIEVEMENTS 

Very early a device oriented approach has been chosen for 
the description of the 3rd generation light source BESSY II. 
A naming convention was developed for easy identification 
and parsing of classifying properties like installation loca- 
tion, device family, type and instance. Around the 'boot- 
strap' information contained in the device names a first ref- 



erence database has been set up describing wiring, cal- 
ibrations, geometries etc. 

2.1 Device I/O 

UtiUsation of the EPICS control system toolkit implicates 
the network protocol called Channel Access for the I/O of 
process variables. At BESSY the device model results in a 
scheme <DEVICENAME> : <channel>. 

Generation of the EPICS Real Time DataBases (RTDB) 
for device classes with high multiplicity and simple I/O 
(power supplies, vacuum system, timings) is based on two 
components: device class specific data are stored in the DB. 
Functionality and logic of <channel> is modelled with a 
graphical editor and stored in a template file. Generating 
scripts merge both into the actual RTDB. 
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Figure 1 : RF Power Units are controlled by flat CAN I/O to 
complex, turn-key PLC systems. Addressing of sub-units 
is done via channel (name) grouping. 

For unique and complex systems (RF, insertion devices) 
structuring takes place in <chaiiiiel> where no common 
naming convention has been defined so far. Contrary to 
the previous approach of complex template/atomic substi- 
tution here all channels involved are assigned to sub-units 
and hierarchies. The structure is fully implemented in the 
DB and for RTDB generation only connected with simple 
atomic templates. 

Intermediate systems (scraper, GP-IB devices) are either 
adapted to one of these approaches or simply set up by ad- 
hoc created files. 



2.2 Conditioning 

Documentation of and transitions between different facility 
operation conditions are handled by a save/restore/compare 



tool that is working on a set of snapshot files. Coarse con- 
figuration is provided by SQL retrievals of name lists. Hier- 
archies and partitioning are derived from device-name pat- 
terns and mapped into directories and files. This is feasi- 
ble only because the relevant channels are restricted to set- 
point, readback and status. Deviations of this scheme are 
few and easily maintainable by hand. 

Information required by modelling tools for conversion 
between engineering units of device I/O and the physics 
views (magnet function, length, position, conversion fac- 
tor etc.) are fully available in the DB [^. Therefore 
the linear optics correction tools (orbit, tune) are instan- 
taneously consistently configured provided the installed 
hardware matches the entries in the DB. 

2.3 Alarm, Archiving 

As long as the alarm handler has to monitor only hardware 
trips DB retrieval of device name collections and script 
based interpretation of device name patterns are helpful at 
least for the simple devices with high multiplicity: typical 
channels are ON/OFF status. Again grouping and hierar- 
chies can be derived from the class description embedded 
in the device name. 

For the complex devices (RF) control functionality and 
logic has already been mapped into DB structures (see 2.1). 



Here genuine DB calls produce alarm handler configura- 
tion files with sophisticated error reporting capabilities. 

In a similar fashion creation of configuration files for the 
data collector engine(s) of the archiving system is simpli- 
fied by DB calls: for each device class a limited number of 
signals and associated frequencies are of interest for long 
term monitoring. The DB basically serves as source for 
device name collections. 

2.4 Data Transfer 

High level software using the CDEV API (configured with 
a device description language file) and 'foreign' networks 
(connected by the Channel Access gateway) benefit also 
from the DB: For CDEV access definition and permission 
to selected I/O channels for each device class is defined by 
appropriate prototype descriptions (in analogy to the RTDB 
templates). The associated lists of devices are compiled 
with DB calls. CA gateway takes advantage of the naming 
convention by regular expression evaluation. 

2.5 Installation Procedures 

Facility modifications typically change the device inven- 
tory. The DB supports consistent propagation of inno- 
vations [|^]: During an installation campaign devices are 
added or deleted in the DB. In addition, new device classes 
are modelled within script logics and template (prototype) 
descriptions. Running the configuration scripts on all con- 
trol system levels updates the configurations within devel- 
opment environment, test system and production area. 



3 SOLVABLE DEFICIENCIES 

A number of restrictions imposed by the present device ori- 
ented DB model are solvable by minor structural modifi- 
cations and consequent introduction of channels necessary 
for the adequate description of essential device properties. 



3.1 Device Ambiguities, Hierarchies 

Dependent on the specific point of view, definition of de- 
vice classes and assignment of equipment comprises ambi- 
guities. E.g. the device class magnet (M) is tightly bound to 
the model aspect of the storage ring, whereas the the class 
power supply (P) covers the engineering aspects of the cur- 
rent converters. Pulsed elements (Kicker, Septa) are very 
similar devices, but do not fit into this scheme - neither into 
the model nor the I/O aspects. The decision to assign a 
single dedicated device-class (K) introduces a new pattern 
(fig. ^ and breaks the naming structure. 
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Figure 2: Ambiguities in device class definition result in a 
complicated naming structure 

Difficulties get worse for complex pieces of equipment: 
insertion devices have to be treated as 'units'. They can be 
completely replaced by different entities with similar com- 
plexity. Typically they consist of a number of devices partly 
belonging to already described device classes (like bipolar 
power supplies). 

The straightforward solution here is the extension of the 
device naming convention: substructures and naming rules 
have to be introduced also for the (up to now monolithic) 
device property describing name element ('genome chart'). 
Corresponding DB structures have to be implemented. 

Similarly naming rules have to be developed where 
structuring takes place in <chcLnnel> (fig. In sum- 
mary, the distinction and boundary between device and 
<channel> are dictated by specifics of the I/O connectivity 
and arbitrary with respect to the required DB structure. It 
does not necessarily coincide with the most adequate clas- 
sification aspects. 



3.2 Context Dependent Role of Devices 

Several global states are well defined for the whole facility 
(e.g. 'shutdown', 'machine development', 'user service' 
etc.) or for sub-sections or device collections: 'injection 
running', 'wave length shifter ON' etc. The role of devices 
depend on these states: in the context of 'shutdown' insuf- 
ficient liquid helium level at super-conducting devices has 
to generate a high severity alarm. For power supplies even 
OFF states are then no failure. But during 'user service' 
alarms should notify the operator already when power sup- 
ply readbacks are out of meaningful bounds. 

Similar case distinctions have to be made for all con- 
ditioning applications (reload constraints for save/restore, 
active/inactive elements for modelling), for data archiv- 
ing (active periods, frequency/monitor mode), for sequenc- 
ing programs etc. Today only the most general con- 
ditions are statically configured and available from the 
database/configuration scripts. Exceptions are partly coded 
within the applications or have to be handled by the opera- 
tors — an error-prone situation. 

A clearly laid out man-machine interface provides an ef- 
fective protection against accidental maloperation. Presen- 
tation details and accessibility of devices should be tailored 
to the user groups addressed: Operators, device experts, ac- 
celerator physicists. The required attributes attached to the 
device channels should be easily retrievable from the DB. 

4 STRUCTURAL SHORTCOMINGS 

4. 1 Immature Data Model 

Starting from the device model a very specific view of the 
control system structure has been mapped into DB struc- 
ture: device classes correspond to tailored set of tables. De- 
viating aspects that do not fit into the scheme are modelled 
by relations, constraints, triggers and presented to the ap- 
plications by pre-built views. The result is not very flexible, 
hard to extend and complicated to maintain in a consistent 
state free from redundancies. Numerous device attributes 
are scattered over template/prototype files and configura- 
tion creating scripts in an imphcit format without clear and 
explicit relation to the data within the DB. 

4.2 Unavailable Data 

Configurations of archiver retrieval tools are much more 
demanding than those of data collector processes. In search 
of correlations arbitrary channel names have to be detected 
by their physical dimension: for a drift analysis the data 
sources for temperatures [C], RF frequency [MHz], BPM 
deviations [mm] and corrector kicks [mrad] have to be dis- 
covered. Any non-static, not pre-configured retrieval in- 
terface to the most important performance analysis tool of 
the facility -archived data- requires clues to signal names, 
meaning, functionality, dimensions, attributes. 

With the RTDB template approach the channel attributes 
are hidden within these files and not available to the DB. 



Consequently, no DB based data relations are available for 
correlations (comparable dimensions), projections (user, 
expert, device responsible) or dependencies (triggered by). 
There is no browsable common data source that allows to 
coordinate consistency of configurations requiring channel 
attributes (that go beyond simple and clear assignments to 
well defined device classes). The device model is tailored 
for modelling applications. For the archiver retrieval it is 
useless continuously causing errors and inconsistencies. 

5 SOLUTION ATTEMPT 

In a kind of clean-up effort the existing fragments used for 
RTDB generation will be put into a new scheme. Sacri- 
ficing the feasibility to generate complex RTDB templates 
with a graphical editor, now device class tables, templates 
and I/O software modules {records) will be put together as 
a new DB core. In view of the extendibility for high level 
applications a purely DB based approach has been taken — 
even though for RTDB generation the framework of XML 
seems to be an attractive and well suited alternative. 

A new entity gadget is introduced connecting the data 
spaces Device, Channel and lOstruct. These DB sections 
have to be set up consequently in 3rd normal form, i.e. all 
device class properties, channel attributes and I/O specifics 
have to be modelled in data and relations, not in table struc- 
tures. In blue -print the resulting data model looks abstract 
and (intimidating) complex, but promising with respect to 
DB flexibiUty, extendibiUty and cleanness. Expectation 
that today's complicated configuration scripts collapse to 
simple sequences of DB queries seem to be justified. 

6 SUMMARY 

The most difficult problem of a comprehensive configura- 
tion management system is the determination of 'natural' 
data structures and breaking them down into localised data 
areas, dependencies and relations. For a relatively small 
installation like BESSY II the expected reward in stabiUty 
and configuration consistency does not clearly justify effort 
and risk of the envisaged re-engineering task. One could ar- 
gue that the present mixture of DB based and hand edited 
configuration is an efficient compromise. On the other hand 
the persistent and boring work-load due to manual config- 
uration update requirements is a constant source of motiva- 
tion to persue this reengineering project. 
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